Mac Mania 2/MacMania 2.toast/Demo's/Tools&Utilities/PowerPC/PPC News 3013

Text File | 1994-05-26 | 18.6 KB | 323 lines | [TEXT/ttxt]

'FIRST TAKE ONE PROCESSOR'... THE PREP RECIPE FOR BUILDING MACHINES

"A huge roller-coaster of a novel crammed full with sizzling gypsies";
was how Edmund Blackadder, the comic creation of Rowan Atkinson
described a book of his. Compared to this, the PowerPC Reference
Platform Specification (Beta Version) will find itself struggling to
compete on the stage of world literature. There are no gypsies, only
some sizzling bus specifications. Neither is it huge. Anyone who has
seen PowerOpen's mammoth ABI and API specifications, will find PReP's
236 pages quite skimpy. Nonetheless, the ring-bound soft-covered volume
is being pawed over by well in excess of 1,000 systems designers today
as they try to decide whether to build PowerPC machines. It is no
exaggeration to say that the PowerPC's success on the desktop will be
built on three foundations: the inherent power of the chip itself;
operating system and application support; and the care with which PReP
is constructed.

As we have reported in the past, (select 3001) the PReP specification is
a collaborative work, currently under the control of IBM, that lays out
in some detail the specifications needed to build a PowerPC clone
capable of running the Workplace OS, Windows NT, AIX; Solaris and
Taligent.

Though notionally a public document, PReP has not always been easy to
get hold of. Requests are fielded either by IBM or its nominated agents
in various countries and there is a registration procedure to go
through. There is no on-line version available either on the Internet or
on CompuServe. IBM explains this omission, partly in terms of the arcane
lay-up language that the PReP is held in (difficult to produce an ASCII
version, they say) and partly in terms of control: the company likes to
know who has a copy. Since the beta version was published in March,
however, access has been eased considerably. A fax to IBM's John
Terwilliger in the US on 512-838-8857 stating Name, Company, Address
Telephone Number, Fax number, Internet address, Type of business,
Alternative contact details and a reason for your request will usually
do the trick, or, you can email him at: [e-mail]. The
Reference document itself suggests that you can try calling (1)-512-839-
2992 or (1)-800-845-6686 in the US, or (39)-39-600-4295 for copies.

Neither, it appears, is there anything to stop you from making further
copies: "...IBM authorises you to copy and distribute this publication
... in any form, without payment to IBM, for the purpose of developing
original publications, code or equipment (except integrated circuit
processors) which conform to this publication" says its initial
copyright notice. The brackets are important - you can do anything you
like, but don't go off and build your own PowerPC processor - IBM
wouldn't like that at all. After all, the whole raison d'etre of PReP is
to keep IBM and Motorola chip factories busy.

Ignoring the thorny question of how acceptable PReP is to Apple, IBM
reckons that the document is nearly finished. It needs to be - IBM's
Power Personal Division is committed to shipping several machines that
comply with the PReP specification, in the second half of this year.
Prolonged wrangling over the spec would either entail a delay to the
machines' launch or a machine that pre-empted the finished standard.
Neither of these options can be palatable to IBM, indeed the combined
wait for PReP and system software are the two factors keeping IBM from
launching machines at the moment; there is little doubt that the
division could have been shipping hardware in volume for months now
without those constraints.

So what will you find as you curl up beside your roaring log fire for an
evening? After the initial pre-amble it is divided into five main
chapters, covering Hardware configurations, Architecture Guidance,
Machine Abstractions; Boot Process & Firmware and the all-important
Reference Implementation, which gives a glimpse at the likely
configuration of IBM's first desktop model. The document is topped off
with 10 appendices, five of which eventually describe implementation
details of the announced compliant operating systems. In the alpha
version, only the Windows NT appendix was in anything like a finished
state. This time around the AIX specifications have been fleshed out and
Workplace OS makes a debut. This leaves the Solaris and Taligent entries
completely blank.

Workplace OS is not the only addition; since the first version, the
authors have made some 67 changes to PReP's pages. Some are, dare we
say, pretty trivial - so now Micro Channel Architecture is spelled out
in full the first time it occurs, in order avoid confusing the poor
folks who might believe that MCA signified the Music Corporation of
America. However, other alterations are more significant:

*LocalTalk now joins Ethernet as a "recommended" networking standard -
an obvious nod towards Apple Computer.

*Compliant machines should now be able to support both "Endian" modes of
operation.

*The section on firmware development has been deleted on the grounds
that it was too product-specific.

*VGA hardware emulation disappears, 640x480 resolution added.

*More detail is added to the multiprocessing section, particularly on
the interrupt handling side.

*The Power Management section has virtually ben re-written.

*NVRAM structure is defined for the first time.

*For the first time, the document outlines a general procedure for
getting systems certified as PReP compliant.

However there are still some places where the specification remains very
sketchy. Don't expect much on audio support, for example; all you will
receive is the bald statement that compliant systems must be able to get
analogue noises in and out and must provide 16 bit stereo samples at a
sampling rate of 44.1kHz and 22.05kHz and that is it.

One of the most quoted items in the whole document must be the table at
the end of chapter two that defines hardware requirements for the
various operating systems. To be precise, there are two tables, one
which describes typical configurations for portable, media-less,
desktop, technical and server machines. The other describes the
resources required to run Windows NT, AIX and Workplace OS.

So, all PReP compliant computers must have a minimum of 8MBytes of RAM,
but it is recommended that they be expandable to at least 32MB. Windows
NT and AIX need 16MB to run, with the claim that the svelte Workplace OS
will fit into 8MB. Hard disk capacity is a little trickier; the tables
show that 80MB is the bare minimum, however all the operating systems
will apparently require at least 200MB of disk space to operate. Indeed
240MB is recommended for all but servers, which should have at least
400MB.

On the connectivity side Ethernet or LocalTalk are the recommended
standards which should be supported. Of course, there is nothing that
stops developers from including Token Ring too, but to see IBM's
erstwhile favourite missing from the recommended list shows that the
company is taking consensus-building seriously. Likewise there are few
mentions of MCA; neither the Music Corporation or the IBM bus standard.
Recommended expansion busses are PCI, PCMCIA and/or ISA (the old AT
bus). Others can be used, but will need changes to the operating
system's abstraction layer.

"Abstraction" is word that you cannot avoid when talking about PReP -
chapter 4 is devoted to it and the concept is key to the document's need
to serve two opposing masters. On the other it has to promote
standardisation, on the other, it has to give manufacturers enough
leeway to differentiate their products. Abstraction is the mechanism
chosen to satisfy these twin goals. Abstraction software concentrates
all of the hardware-dependent operating system code into a single bundle
with well-defined interfaces to the operating system kernel. The idea is
to isolate the operating system from the vagaries of the hardware so
that the hardware designer can do anything he or she likes under the
hood, as long as the correct set of interfaces are maintained.

To the casual observer, the way in which PReP places the onus of
abstraction on the operating system writer is curious. It might be
thought that the hardware manufacture should be responsible for hiding
the details of implementation under a thin software abstraction layer,
however PReP makes it clear that it is the OS-writer's job to write the
initial abstraction software, but must also provide a mechanism so that
the PC maker can amend those parts that need to be changed due to
proprietary hardware technology.

The abstraction software falls into three main classes; Boot-Time
Abstraction Software (BTAS), Run-Time Abstraction Software (RTAS) and
device drivers (shamefully, these don't have an abbreviation). BTAS
abstracts the hardware used to boot the machine; these include disk and
network interfaces needed to load the binary into the machine, as well
as the keyboard and display. RTAS handles stuff like interrupt
controllers and cache configuration.

Again, the boot process merits a substantial section of its own and
chapter 5 goes into considerable detail explaining what should load what
into where. It is a "strategic objective" to see PReP compliant hardware
conforming to the IEEE P1275 "Open Firmware" draft standard. Why? so
that a standard boot process can be used irrespective of system
configuration. Open Firmware goes way beyond the ability for a machine
to boot its core services; it gives adapter card manufacturers the
ability to design cards that will work irrespective of the processor
type. Put very simply, the Open Firmware-compliant machine will include
a ROM-based Forth interpreter, while the cards will contain small
programmes written in Forth that specify their set-up and configuration.
There are a number of refinements, of course - the Forth commands are
held in a 'tokenised' form, called FCode, to save space, for example.
The net result is that everything from the initial hardware test,
through discovery and initialisation to starting up the console, can be
placed under the control of the open, extensible Fcode language. The
early work on what is now called Open Firmware was carried out by Sun
Microsystems and the technology already appears in Sun's machines.

You may be wondering where chapter 3 went. We skipped it in our haste to
jump into the delights of abstraction. But as it happens, that chapter,
headed "Architecture Guidance" is intimately connected with the sixth
section in the tome "the reference implementation". They are, by far,
the longest two sections in the work. The former sets out the
theoretical architecture that PReP-compliant machines should follow -
Bi-Endian operation, bus structure, the memory map and multiprocessor
considerations are all there. The reference implementation puts the
architecture into practice and presents a complete blueprint for a
generic PowerPC-based machine. It is generally accepted that at least
one of IBM Power Personal's forthcoming machines will bear a striking
resemblance to this implementation.

The PReP architecture defines a hierarchy of buses. At the top is the
64-bit PowerPC bus used for shuttling data between processors, cache and
system memory. This primary bus is connected via a bridge to a secondary
bus supporting all of the other I/O devices. If necessary a slower,
tertiary bus can also be implemented; bridged onto the secondary one.
The reference implementation shows the architecture to the fullest. The
secondary bus is a 32-bit PCI affair, which has the video display system
(with integral VRAM) and a SCSI-2 port attached. A 16-bit ISA bus hosts
audio, and floppy drives. Both have spare slots available.

Rather than attempting a definitive description of the architecture and
reference platform - you can get your own copy if you want that - it's
worth highlighting some of the more noteworthy parts. For example,
though there is no reference to upgradeability in the PReP architecture,
the reference machine includes a 200-pin upgrade slot attached to the
processor bus. This can be filled with either an L2 cache card or a
processor upgrade card. Unfortunately, the beta version of the document
makes it explicit that this slot cannot be used for multiprocessing, so
while you will be able to shove a shiny new PowerPC 604 processor into
the machine, the old 601 will be disabled.

Though you can't achieve multiprocessing through this slot, symmetric
multiprocessing is covered in some detail in the beta version of PReP. A
new section in chapter 3 gives a detailed scheme for arranging
interrupts in an SMP PowerPC-based system, and appendix A gives a
potential two-way implementation for developers to ponder. Basically it
boils down to more level-2 cache, multiple PCI buses and more system
memory. There also needs to be additional facilities for handling
interrupts and interprocessor communication. The 601 and 604 processors
provide a number of commands for keeping processors synchronised. These
are missing from the 603.

"Endianess" is another subject that crops up repeatedly in the Reference
Platform specification. Its etymology dates back to 1726, when Jonathan
Swift wrote Gulliver's travels and of a people warring over the most
appropriate end to crack a boiled egg. Swift fell upon the feud between
the 'Big-Endians' and the 'Little-Endians' as the crassest, most
pointless argument he could invent, and it is appropriate that its name
lives on to describe an arbitrary schism which has divided the processor
world for its entire history. A Big-Endian processor is one which stores
applications and data in the format big end first, most significant byte
first. A Little-Endian processor stores it little end first, least
significant byte first. Imagine a world where some people wrote English
"like this" and others wrote "siht ekil" and you have more or less got
it. Endianess is arbitrary, as far as anyone can argue, one is not
better than the other, however, over the years, some manufacturers have
adopted Big-Endian methods (IBM's POWER architecture, Motorola's 68000
family) while others have opted for little Endian; notably Intel.

It is not easy to isolate the operating system from the Endianess of a
processor, so, in keeping with their heritage , AIX and the Macintosh
system software are Big-Endian, Windows NT and OS/2 for the PowerPC (nee
Workplace OS) are Little-Endian. So how do you support all of these on
one computer platform? You make it Bi-Endian. Natively, the PowerPC is a
Big-Endian chip, however at the flick of a bit it can swap its
proclivities. PReP compliant machines must be able to run in either
mode. Apple Computer nearly managed to make its hardware Bi-Endian, but
apparently fluffed it - a very few components in the Power Macintoshes
only work in a Big-Endian manner, however Apple intends to fix this in
future machines - a step on the long road to PReP compliance.

Being Bi-Endian does not require that the platform can simultaneously
support Big and Little-Endian software simultaneously. The processor's
Endianosity is set at boot time, and a system reset is required to
change this. Theoretically, it is possible to build a machine which,
though emulation and translation software could run both at once, this
would be a so-called "Mixed-Endian" machine. Unfortunately the cost in
processing terms would be ruinously expensive. The Endian question has
more than a theoretical bearing, It means that building a Apple System 7
personality to sit on top of Workplace OS is a tough task. Likewise
producing an AIX personality will be no mean feat.

Which brings us neatly to the appendices, with their descriptions of the
various operating systems. By far the most revealing is the section on
AIX. It is from here that the rumours of Personal AIX spread - a pre-
amble talks about The AIX 4.1 Personal Productivity Client (shortened
later to Personal AIX) and explains that it "represents a major
improvement to the terms and condition and packaging for AIX
(translation - you will be able to get single user licences cheap). It
is being aimed at engineers and researchers who want an entry level
workstation-cum-personal computer and will come pre-installed.

Pay particular attention, as you flick through, to the section on the
AIX Hardware Abstraction Layer. Today AIX doesn't have one - not a
microkernel, or a thin layer of isolating code in sight. Moreover, there
is no commitment to ever produce one, which would be necessary to turn
AIX into a card-carrying "PReP Compliant" operating system. The section
on AIX's HAL begins "IBM makes no claim that this [the HAL] will ever be
implemented or that the abstraction will ever allow a 'shrink wrapped'
AIX or allow a third party to provide components of the abstraction". In
other word, AIX may continue to break all the rules. To confuse thing
slightly, the AIX team in its "initial design investigation" talks about
a Portability Assist Layer, rather than a Hardware Adaption Layer, but
the outlined approach looks identical. There is, of course, absolutely
no reason why IBM should re-architect AIX, it was designed for the
POWER/PowerPC architecture and is perfectly happy running on the naked
hardware. Still, it does reveal a certain chutzpa, when the rest of the
document is dedicated to trumpeting the importance of compliance. It
also means that the first PowerOpen implementations (based upon AIX)
will not be able to carry the PReP compliant stickers.

By contrast, both Windows NT and Workplace OS are well behaved, though
there is not much new to be gleaned. The Windows NT Hardware Abstraction
Layer looks like a good match for PReP's Run-Time Abstraction Layer.
There is still a big hole, however where the section on Boot Time
Abstraction Requirements is meant to be, so no details on the OS loader
that NT expects to use at Boot Time. Judging by the number of developers
who are playing with NT on machines, however, it would seem that at
least someone has an idea or two on this. Likewise, Workplace OS's
microkernel structure serves to bundle all of the hardware specific code
into one, small, well-defined place.

Not a very large book, then to define an entire computer architecture,
but still substantially larger than the non-existent tome that today's
PC industry is based upon. As the Reference Platform points out, when
defining the ISA bus, the simplest definition is "Whatever it takes to
make the most adapters pluggable". Final judgement will depend on the
contents of the final version due out later this year, and ultimately on
the number of companies which decide to follow its edicts and get
awarded the sticker of compliance. Exactly what will be written on the
sticker is still a matter for debate. Pending market analysis "A
hardware platform will be branded as 'PowerPC Reference Platform
Compliant' (or something of a similar nature)", say the document's
authors, rather sheepishly. Time to wheel out the marketeers methinks.

(c)PowerPC News -  Free by mailing: [e-mail]